PD ROM 1/PD ROM Volume I - Macintosh Software from BMUG (1988).iso/Electronic Messages/USEnet Digests/USEnet Vol. 4/USEnet 4.26

Text File | 1988-04-08 | 30.4 KB | 780 lines | [TEXT/ttxt]

22-Feb-88 15:21:14-PST,31848;000000000001
Return-Path: <[e-mail]>
Received: from RELAY.CS.NET by SUMEX-AIM.Stanford.EDU with TCP; Mon, 22 Feb 88 15:18:38 PST
Received: from relay2.cs.net by RELAY.CS.NET id ab15561; 22 Feb 88 13:55 EST
Received: from relay.cs.net by RELAY.CS.NET id aa11298; 22 Feb 88 13:37 EST
Received: from sdr.slb.com by RELAY.CS.NET id ad11263; 22 Feb 88 13:32 EST
Date: Mon, 22 Feb 88 12:51 EDT
From: Jeffrey Shulman <[e-mail]>
Subject: Usenet Mac Digest V4 #26
To: [e-mail], [e-mail]
X-VMS-To: in%"[e-mail]",in%"[e-mail]"

Date: Mon 22 Feb 88 12:51:21-EDT
From: Jeff Shulman <SHULMAN@SDR>
Subject: Usenet Mac Digest V4 #26
To: Usenet-List: ;
Message-ID: <572550681.0.SHULMAN@SDR>
Mail-System-Version: <VAX-MM(218)+TOPSLIB(129)@SDR>

Usenet Mac Digest     Friday, February 19, 1988      Volume 4 : Issue 26

Today's Topics:
     Re: SysEnvirons inconsistency
     Re: LSP keyboard EOF
     A serial port "pipe"
     Re: Bug in LaserWriter Driver 5.0
     Re: Versaterm 3.1 background "send file"
     Re: Why Do I need Kinetics Box?(Unix<>Mac)
     Tasking on the Mac (was: stack sniffer evils)
     Re: LSP keyboard EOF
     Video DRAMs
     Re: Option key death
     General Computer/Hyperdrives a summary..
     Re: Bug in LaserWriter Driver 5.0
     Re: Changing the Hard Disk Icon?
     Re: MacRISK Patch
     Re: A Few Good Rumors...
     Asynchronous LaserWriter
     LED Transparency Projectors?
     Re: A/UX cost

----------------------------------------------------------------------

From: [e-mail]
Subject: Re: SysEnvirons inconsistency
Date: 15 Feb 88 00:24:00 GMT


[e-mail](Bill ??) writes in comp.sys.mac

>There is an inconsistency in Inside Macintosh V regarding the definition of
>SysEnvirons. In the text it says that SysEnvirons expects to be passed a
>pointer to a record which it will fill out with environment information. In
>the end-chapter summary it says that SysEnvirons expects the actual record.
>This matters, you see, because if the record gets expanded later to contain
>more information, I don't want my stack to be destroyed. Will future versions
>of SysEnvirons be smart enough not to fill out a version 2 record if I only
>request version 1? The LightSpeed Pascal interfaces believe the summary at the
>end of the chapter.
>
    As I understand the SysEnvirons call (don't have my IM in front of me
so I am doing this from memory).  It takes the record itself and then
fills it in based on the version number that you pass it.  I believe
that if you ask for version 2 and there is only a version 1 that you
will get version 1, but if you ask for version 1 and there is a version
2 it does not give you version 2.
--
+---------------------------------+-----------------------------------+
+                                 +  Any thing I say may be taken as  +
+   Leonard Rosenthol             +  fact, then again you might decide+
+   President, LazerWare, inc.    +  that it really isn't, so you     +
+                                 +  never know, do you??             +
+   [e-mail]     +                                   +
+   GEnie:  MACgician             +                                   +
+   Delphi: MACgician             +                                   +
+                                 +                                   +
+---------------------------------+-----------------------------------+


------------------------------

From: [e-mail]
Subject: Re: LSP keyboard EOF
Date: 15 Feb 88 00:34:00 GMT


[e-mail](H. George Friedman, Jr.) writes in
comp.sys.mac

>A LightSpeed Pascal question:
>
>In reading from standard input, from the keyboard, is there any way to
>signal end of file to the program?  I can't find any indication in the
>manual.
>
>Thanks to anyone who can help.
    I believe (and Rich will correct me if I am wrong, won't you Rich?)
that you can signal the end of file the same way you would if you were
working on a Unix machine (for example) by using a Cmd-D (or Control-D,
to those Unix folk). I think that the reason for this is that Cmd/Ctl-D
is a Pascal standard.
--
+---------------------------------+-----------------------------------+
+                                 +  Any thing I say may be taken as  +
+   Leonard Rosenthol             +  fact, then again you might decide+
+   President, LazerWare, inc.    +  that it really isn't, so you     +
+                                 +  never know, do you??             +
+   [e-mail]     +                                   +
+   GEnie:  MACgician             +                                   +
+   Delphi: MACgician             +                                   +
+                                 +                                   +
+---------------------------------+-----------------------------------+


------------------------------

From: [e-mail] (Erik Kilk)
Subject: A serial port "pipe"
Date: 12 Feb 88 16:48:13 GMT


SERIAL PORT "PIPE"

I'm looking for a program which will read from one serial port, dumping
what it reads to a file, WHILE an application is printing out the other
serial port.  What I want to do is connect the two ports together so I
can capture what is heading towards the printer (which will then be
downloaded to a larger workstation.)

I may attempt to write something if noone has anything like this.  Any
suggestions on techniques?  I'm very capable with Mac and interrupt
routine programming, but just don't have too much time on my hands to do
the trial and error investigating.

Erik Kilk


------------------------------

From: [e-mail] (Bayles Holt)
Subject: Re: Bug in LaserWriter Driver 5.0
Date: 15 Feb 88 18:59:02 GMT
Organization: Apple Computer Inc., Cupertino, USA

In Article 13801 Edward Moy writes:
>I don't know if this has been mentioned before, but has anyone noticed that
>LW 5.0 doesn't create the Chicago font correctly, either when downloading
>to the LaserWriter or when creating a PostScript file.  The glyphs for the
>characters 17-20 (command, check mark, diamond and apple) are missing, so
>these symbols don't appear in the final output.  I checked LW 4.0 and it
>properly creates these glyphs.

I tried to duplicate the problems you mention in version 5.0 without
success. Perhaps you could forward specific info about how to duplicate
the problem such as the document, font size, and application you were
using.

As a initial guess to such behavior I might offer the following
explanation and you can judge as to its applicability.  Some of the
early bitmap fonts were created with different characters in different
point sizes. That is, Chicago 12 point might contain the "missing"
characters while Chicago 18 point (or some other size) might not.  When
a document with 12 point Chicago is printed, the LaserWriter driver
selects the 18 point font to print (because it prints better at the
higher resolution) and ends up without the characters in question.  The
practice of putting different characters in different point sizes is
discouraged, but you can check this out very easily, just see if you
have more than one point size of Chicago in your font menu.

>On the subject of bugs, both 4.0 and 5.0 won't print italicized Chicago either.
>The 3.x series worked fine.

The Italic style variation also seemed to work fine for me.  Again by
way of explanation, the original LaserWriter contained a bug in
PostScript where italicizing a bitmap object such as a font character
did not work when the character being rendered was exactly the right
size for printing and did  not require scaling.  Again this is easy to
test just by setting the point size to some other size and see if the
problem goes away.

Otherwise...  If there are additional comments or questions, you may
reply to me directly.
--
--Bayles Holt
[e-mail]
APPLELINK: HOLT2


------------------------------

From: [e-mail] (Clive Steward)
Subject: Re: Versaterm 3.1 background "send file"
Date: 15 Feb 88 02:08:17 GMT
Organization: resident visitor

>From article <[e-mail]>, by [e-mail] (Michael Sonnier):
>
> I have experienced some problems using "Send File" from Versaterm 3.1 under
> Multi-finder.  The file transfer works ok and I can switch back to multifinder
> or to another application while the transfer is in progress.  However if I
> have not returned to Versaterm when the transfer ends I get the beep
> notice that transfer is finished (if that option is on) and then Versaterm
> dies!  When I return to Versaterm there is an error window with message that
> Versaterm has unexpectedly quit (or some such garbage...).  Has this happened
> to anyone else?  Any ideas why?

Yes, it happens, and yes, ideas why.

Xon-Xoff flow control is dependent on the shutoff response happening
before  the receive buffer actually overflows.  On many (especially
Unix) systems with  front-end processors (which includes the archtecture
of many minis and super-micros, as well as mainframes), this timing can
be long, if the fep isn't carefully designed to prevent it.

Many dumbish terminals (some you doubtless know very well) don't really
flow-control successfully at 9600 baud or above.

Versaterm does seem to have a problem, specifically during that moment
when the window display is changing from the 'file transfer' setup back
to normal terminal screen.  For those of you without, the main window
shrinks, and a non-modal dialog comes up with a ruler, both small enough
that you can click things behind easily to do something else while the
transfer happens in the background).

I have the problem, only at the beginning of a transfer, if I try to
switch under Multifinder before the transition occurs.  When it happens,
same unexpected quit situation.  I think flow control failed, and that
Versaterm or its stack then gets overwritten.

I haven't observed the problem, even at 19.2kbaud, so long as I let the
windows change before changing to another task.  I also haven't seen it
ever at the end of a transfer, so wonder if you're really getting the
'begin'.

As to why, or how to fix -- Versaterm either needs a longer internal
buffer for those of us who run it fast (it works so well, otherwise, at
speed -- really fast xmodem decoding), or there is a fix needed for
something about the window transition period.

It's a great program, just has a bug.  Still highly recommended.

Clive Steward

[ This has been corrected in a later version (see later article) - Jeff
]


------------------------------

From: [e-mail] (;;;;YF37)
Subject: Re: Why Do I need Kinetics Box?(Unix<>Mac)
Date: 16 Feb 88 02:11:02 GMT
Organization: University of California, Berkeley

In article <[e-mail]> [e-mail] (David Williams)
writes:
>Ok you LocalTalk/Ethertalk/Ethernet gurus: A Question...
>
>Now that there are Ethernet cards for the SE and the II why is a Kinetics Box
>(or like boxes) necessary? Will there be a version of AUFS/CAP stuff that does
>not require a box between my Mac II w/EtherTalk and my Hp Unix box on the
>ethernet? If not, WHY NOT?

Currently, a K-Box is required because it has to run the KIP code, that
takes AppleTalk packets on the LocalTalk network destined for ethernet,
and encap- sulates then into UDP packets.  The EtherTalk cards just send
AppleTalk packets on the ethernet, which makes them incompatible (or at
least ignored) by the rest of the TCP world, including the CAP/AUFS
software.  Hopefully, someone (soon) will write a driver for the
EtherTalk card that will encapsulate packets just like the KIP code.

>And just where might NFS fit into this scheme? I know TOPS is working on
>incorporating this into TOPS to some degree. However, the cost has to be
>reasonable, as I am the only Mac II user in my lab, and we are not about to
>spend big bucks for just one user.
>

We are a test site for a version of MacNFS from Univ. of Michigan, I
believe. I don't think we've received it yet, but when we do, I post as
much info about it as I can, depending on non-disclosure agreements,
etc.
--
Edward Moy
Workstation Software Support Group
University of California
Berkeley, CA  94720

[e-mail]
ucbvax!violet!edmoy


------------------------------

From: [e-mail] (Roland Conybeare)
Subject: Tasking on the Mac (was: stack sniffer evils)
Date: 11 Feb 88 03:13:29 GMT
Organization: Comp Sci, Monash Uni, Australia


    I have received several responses to my posting about stack sniffer
problems when multitasking on the Macintosh.  This posting summarises
the information I have learnt.  Thank you to all the people who wrote to
me, particularly Paul Mercer and Bryan Stearns from Apple, who
entertained several exchanges of E-mail.

    Quick summary: there's more to getting tasking to work on the Mac than
just disabling the stack sniffer.

    Normal operation of the Macintosh depends on the following model of the
Mac's memory being correct:

        +----+
        |    |
        |    |
        +----+ <-- SP
        |    |
        +----+ <-- StkLowPt ($00000110)
        |    |
        +----+ <-- HeapEnd
        |    |
        |    |
        +----+

    The sniffer invokes a system error if SP < StkLowPt.  Normally,
StkLowPt will be moved by the Memory Manager when the heap expands.
However, I understand that *if* StkLowPt is 0, the sniffer is *disabled*
and the Memory Manager will no longer alter StkLowPt when the heap
changes size. The sniffer can be re-enabled by putting -1 in StkLowPt.

    However, we are not out of the woods yet!  QuickDraw expects HeapEnd to
be less than SP.  Some QuickDraw operations (I don't know  the complete
subset, but certainly CopyBits and region operations) divvy up memory
between HeapEnd and SP into buffers.  Note that this is not the same as
just using lots of stack space.  To call QD without error, *all* memory
from HeapEnd to SP must be unused.

    A consequence of QD's behaviour is that we cannot blithely move SP
around, even if we promise to keep it out of the heap, if we also want
to call QD.

    Now for some implementations.  There are a number of approaches I know
of for making tasking work, as follows:

Avoiding the Stack Sniffer:

(1) we allocate space for each task's stack on the heap (this is known
    as a 'cactus' stack).  Tasks may release stack space, leaving
    'holes'.  The memory in these 'holes' becomes available again when
    the lower limit of the stack moves up to expose the hole again.

    This approach avoids the sniffer entirely, but we can't call QD from
    such a stack organisation.

(2) allocate each task's stack on the heap.  Now the community of
    tasks can be dynamic, although the heap may well become fragmented,
    since it is difficult to make stacks relocatable.

    This scheme can be made to work by storing zero in StkLowPt,
    disabling the stack sniffer.  We still need to call QD from the
    'system' stack.

Calling QD correctly:

(3) we could have one process permanently residing in the system stack,
    said process taking responsibility for all QD calls.  The trouble
    with this is it will also have to handle any other toolbox call
which
    uses QD.  We will pay a high price for this service, that is, two
    context switches of 20-30 instructions each, per toolbox call.

(4) Even better, we reserve stack some stack space above HeapEnd for
    calling QD.  To make a toolbox call, we just move the stack pointer
to
    this reserved area, call the appropriate trap, and return the stack
    pointer to its original value.  This approach works because every
    68000 compiler I have seen uses A6 to refer to local variables,
    and thus doesn't even notice that we have moved the stack.
    We have to be careful to keep enough 'normal' stack space available
    in this way, or we can't call QD anymore.  I recall around 3K being
    sufficient for CopyBits...

    The price of (4) is simply that our code gets bigger: several
    instructions per toolbox call of overhead, if we do the above stack
    finessing inline.

BTW, while the disabling of the sniffer is not documented as far as I
can tell,  I would not expect it to break, since Apple is reportedly
rewriting the toolbox with several goals including 'better support for
multitasking'. I hope this means that traps will make fewer assumptions
about the Mac's memory organisation.

I hope this posting helps someone else avoid the stackfalls :-) of
taking the Mac to task.
--
Roland Conybeare
([e-mail])


------------------------------

From: [e-mail]
Subject: Re: LSP keyboard EOF
Date: 15 Feb 88 19:18:00 GMT


>    I believe (and Rich will correct me if I am wrong, won't you Rich?) that
>you can signal the end of file the same way you would if you were working on a
>Unix machine (for example) by using a Cmd-D (or Control-D, to those Unix folk).
>I think that the reason for this is that Cmd/Ctl-D is a Pascal standard.

I think I had tried that, but will try it again.

I have also (so far) gotten email responses from Richard Siegel of THINK
([e-mail]), who suggested the Enter key, but only if using
the old Mac keyboard; and from Ken Hancock ([e-mail]),
who suggested Cmd-Shift-3.

I haven't tried any of these yet, but will do so soon.

Thanks to all three of you for the help!


               H. George Friedman, Jr.
               Department of Computer Science
               University of Illinois at Urbana-Champaign
               1304 West Springfield Avenue
               Urbana, Illinois  61801

               USENET:    ...!{pur-ee,ihnp4,convex}!uiucdcs!friedman
               CSNET:    [e-mail]
               ARPA:    [e-mail]


------------------------------

From: [e-mail]
Subject: Video DRAMs
Date: 15 Feb 88 22:20:00 GMT


For those of you with Mac II/Apple video cards:

I just talked to Microprocessors Unlimited in Dallas.  They are a
low-cost mail-order chip merchant.  As little as 4 weeks ago, they were
selling NEC 41264 video DRAMS (64K*4) for $5.25 each.  The Apple
256-color upgrade is 8 of these chips.  However, four weeks ago NEC cut
back supplies so that they could fully supply OEM manufacturers.

The chips have skyrocketed to $9.50 each.  This means a "do it yourself"
video upgrade is now $76, as opposed to $44.  I wonder if things will
get better or worse?  Can you still get the good prices somewhere?  Does
someone (Mac mail-order house?) have a stockpile of these chips?

Don Gillies {ihnp4!uiucdcs!gillies} U of Illinois
            {[e-mail]}


------------------------------

From: [e-mail] (73539000)
Subject: Re: Option key death
Date: 16 Feb 88 05:24:32 GMT
Organization: University of California, Santa Cruz; CATS

Yep, My option key on my Extended Keyboard on my Mac II running 4.2/6.0
has been stuck down before. And to top it off, I have had my Caps Lock
light get stuck on, when the button is still up! It must be a bug in the
ADB driver.

To Apple: How does one light the Num Lock or Scroll Lock keys from a
program?? IM vol V has no info on this subject and I don't feel like
dissassembling the ADB driver to see how the Caps Lock light works, and
then guesstimate the method for the others. I am sure that the
development community would like a tech note on this, as many people are
now diddling with emulation of YOU-KNOW- WHO machines and UNIX stuff,
where these lights may be useful.
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~  Alexander M. Rosenberg  ~ INTERNET: [e-mail]   ~ Yoyodyne    ~
~  Crown College, UCSC     ~ UUCP:...!ucbvax!ucscc!ucscb!alibaba~ Propulsion  ~
~  Santa Cruz, CA 95064    ~ BITNET:[e-mail]  ~ Systems, Inc~
~  [phone]       ~ Disclaimer: Nobody is my employer  ~ :-)         ~
~               ~ so nobody cares what I say.    ~          ~


------------------------------

From: [e-mail] (W. Michael Babineau)
Subject: General Computer/Hyperdrives a summary..
Date: 15 Feb 88 22:16:38 GMT
Organization: U. of Waterloo, Ontario

Thanks to everyone who responded to my query related to the reliability
of General Computer Hyperdrives. I have decided to buy a Rodime external
20meg drive for my Mac +.

To summarize the responses I got (both postings and E-mail):
  - the FX-20 external drives by GC appear to be ok
  - the internal drives were strongly NOT recommended as these
     have caused a lot of heart-ache to their owners..
  - GC is slow at upgrading their software when there is a new
    Apple System release, this means that owners have to wait
    for upto a few months before they can upgrade their system
    folders and still have their HD function ok.
  - a few people suggested that, considering what else is available,
    they didn't feel that it was worth it to by a GC product unless
    you have a good dealer who is very willing to go to bat for you.


    Thanks again to all those who responded...


------------------------------

From: [e-mail]
Subject: Re: Bug in LaserWriter Driver 5.0
Date: 15 Feb 88 17:44:00 GMT


    My SigmaEdit DA (which is also written in Lightspeed C) also has to
detect the Edit command based on the current keydown event and detect it
that way.  This, however, poses a problem for international use (except
that to my knowledge and experience with the int'l system the cmd keys
for the Edit menu are still the same).
--
+---------------------------------+-----------------------------------+
+                                 +  Any thing I say may be taken as  +
+   Leonard Rosenthol             +  fact, then again you might decide+
+   President, LazerWare, inc.    +  that it really isn't, so you     +
+                                 +  never know, do you??             +
+   [e-mail]     +                                   +
+   GEnie:  MACgician             +                                   +
+   Delphi: MACgician             +                                   +
+                                 +                                   +
+---------------------------------+-----------------------------------+


------------------------------

From: [e-mail] (ephraim vishniac)
Subject: Re: Changing the Hard Disk Icon?
Date: 16 Feb 88 16:19:27 GMT
Organization: Thinking Machines Corporation, Cambridge, MA

>The icon is actually stored in the driver for the disk (so you can forget about
>using ResEdit to change it -- although in theory it should be possible to
>change).  So... I hope you like your disk icon.  :-)

It's not *that* difficult!  The icon has the same format as an ICN#
resource, though it's not stored as a separate resource.  It's not too
hard to find using ResEdit, as it's immediately followed by the "Where:"
string for the drive.

To replace it, make a new ICN# using ResEdit.  Close that ICN#, then
option-open it again so that you're looking at the hex representation.
Paste that in place of the exact same number of bytes in the driver,
where you've located the old icon by looking for the "Where:" string.
Then, use your modified installer to re-install the driver on your hard
disk.

Since this is a moderately hazardous procedure (not difficult, just
dangerous), be sure to modify a *copy* of your installer, and run it on
a scratch hard disk :-).
--
Ephraim Vishniac                      [e-mail]
Thinking Machines Corporation / 245 First Street / Cambridge, MA 02142-1214


------------------------------

From: [e-mail] (Larry Rosenstein)
Subject: Re: MacRISK Patch
Date: 16 Feb 88 17:21:52 GMT
Organization: Advanced Technology Group, Apple Computer

In article <[e-mail]> [e-mail] (Jerry Whitnell)
writes:
>
>Doesn't work so well on the Mac II.  The problem is they change the
>value returned by GetWMgrPort (used to return a WindowPtr, on the MAC II
>it returns a CWindowPtr).

Not true.  GetWmgrPort returns an old-style port on a Mac II.  The
problem is that on an Apple Video Card the rowBytes field is 128.  I
think that Risk is trying to compute the number of bytes on the screen
and assuming that it won't be more than 32K, which isn't true in this
case.

Also, since Risk isn't compatible with color, then it doesn't matter
which patch you apply.  It is saving the bits into an offscreen black &
white buffer, which only has to be 1 bit deep.

--
Larry Rosenstein

Object Specialist
Apple Computer

AppleLink: Rosenstein1
UUCP:  {sun, voder, nsc}!apple!lsr
CSNET: [e-mail]


------------------------------

From: [e-mail] (William R. Pearson)
Subject: Re: A Few Good Rumors...
Date: 16 Feb 88 22:55:53 GMT
Organization: University of Virginia, Charlottesville


    The thing to remember about a MacII, as opposed to a Sun 3/50 or Sun
3/60, is that it is an expandable machine with a bus. (One should also
consider that the cost of a Sun 3/60 with a 144 Mbyte drive and 8 Meg
memory + tape is around $19,000 list, let's not compare Apple list
prices with Sun discounted prices).  If you want to get a Sun with any
kind of expansion capability, you have to buy a $25,000 (list) machine.
While Apple is going to have to come up with some way to let people buy
A/UX without purchasing an 80 Mbyte disk (since people are using 300
Mbyte Wren IVs which cost around $3K), Apple's list prices are NOT out
of line with other 68020 offerings, especially for machines with busses.

    The prices are farther out of line compared to an IBM PS/2-80 or a
Compaq 386/20 with Xenix/Unix/AIS, but again, not so far out of line
compared to those manufacturer's list prices.  The problem(?) is that no
manufacturer can compete with a $5000 no-name 386 clone with a 100 Mbyte
drive and Xenix/Unix.  But those machines do not offer a standard
graphics interface, the potential to run Mac programs, or the support of
a major manufacturer.

    I wonder how many of the net-readers pay list price for any of these
products?  Comparing Apple list to Sun/IBM/clone discount is a bit
unfair.
--
Bill Pearson
[e-mail]


------------------------------

From: [e-mail] (lee daniels)
Subject: Asynchronous LaserWriter
Date: 15 Feb 88 18:35:43 GMT
Organization: HHB Systems, Mahwah, NJ


    Recently I downloaded Apple's Async LaserWriter driver from Compuserve
    that is supposed to allow printing to a LaserWriter that is
    connected to a Mac serial port either directly or indirectly through
    a modem.

    I have not been able to get it to work.  I have tried installing the
    driver and the ACL files onto the system that came with my SE and
    also into the current multifinder version of the system, with
    identical results.

    When I try to print, I get a dialog telling me that the system is
    looking for my LaserWriter, followed a moment later with a dialog
    telling me that it can not Open the LaserWriter.  I am trying this
    with a direct printer cable from the mac to the printer.  I know
    that my communication is good because I have used interactive mode
    on the printer.

    One thing that I do not understand is a field asking for "Connect Via"
    in the chooser dialog that allows for configuration of the
    communication parameters for the connection.  I have tried specifying
    just about everything in that field including Direct and Direct.ACL.
    I have tried printing from Word 3.0, MacWrite, MacDraw, MacPaint and
the     Finder with no success.

    I need help!!  Has anyone else tried to use this driver and if so
    how did you get it to work if you did.

    Thanks in advance for any information you can give me.

    Lee Daniels

    HHB Systems
    1000 Wyckoff Avenue
    Mahwah, N.J. 07446

    Net address: uunet!philabs!hhb!lee or uunet!princeton!hhb!lee


------------------------------

From: [e-mail] (Mark Rinfret)
Subject: LED Transparency Projectors?
Date: 16 Feb 88 19:37:03 GMT
Organization: Aquidneck Management Associates

Our company is searching for a reasonable quality transparency projector
for a Mac SE or Mac II.  We recently tried Network Specialties Flat Top
but were very disappointed with the contrast and purity of the projected
image.  We have info on others but can't get a demo before making a
purchase, and a purchase/return seems to come bundled with a "restocking
fee".  Has anyone out there had direct experience with any of the
currently available units? I would appreciate hearing from you.  Thanks.

Mark

--
< Mark R. Rinfret,  [e-mail] | ...rayssd!galaxia!amanpt1!mrr    >
< Aquidneck Management Associates       Home: 401-846-7639                   >
< 6 John Clarke Road                    Work: 401-849-8900 x56               >
< Middletown, RI 02840              "If I just had a little more time...">


------------------------------

From: [e-mail] (Ed Tecot)
Subject: Re: A/UX cost
Date: 16 Feb 88 21:53:19 GMT
Organization: Apple Computer Inc., Cupertino, USA

In article <[e-mail]> [e-mail] (Bradford Needham)
writes:
>In article <[e-mail]> [e-mail] (Jerry Whitnell) writes:
>>A/UX... comes preconfigured on either an internal ($4,879)
>>or an external ($5,549) ... upgrade package....
>
>I'm constantly amazed at Apple's marketing sense of humor.
>Haven't they priced Sun's lately?
>
>
>Brad Needham
>[e-mail]

I was shocked to see this as well.  So I did a little research.  Some of
the information above is misleading, here are the details:

M8011 internal A/UX bundle                $3182
    contains:    (1) M0692 internal HD80 with A/UX
            (1) M0693 A/UX accessory kit

M8033 Mac II A/UX upgrade kit                $4879
    contains:    (1) M8011 internal A/UX bundle
            (1) M0221 PMMU chip
            (2) M0219 2MB RAM Exp. Kit

Kits with an external disk are $100 extra.

What this means:

Those of you who already have the PMMU and necessary RAM need not spend
another 5K to get A/UX, all you need is one of the bundle kits at either
$3182 or $3282.

Some interesting notes:

The retail price on an Apple HD80SC internal is $3199 (I called Priority
One for this price).  2MB expansion kits are $599 apiece (if you can
find a lower price, buy it - this is a good price). The remaining $499
in the M8033 is for the PMMU.

What surprises me:

Is in retrospect, just how reasonable this is.  A/UX is essentially free
with the purchase of an 80 meg hard disk from Apple.  Now before you go
say how high that price is (a Jasmine 80 meg drive is about half that
price), keep in mind that this is RETAIL, and actual prices will come
down fast (Priority One sells the 80SC internal for $2779, and I'm sure
you can beat that).  In addition, those of you who don't insist on Apple
labels on everything can go to third parties for the PMMU and RAM.

In summary:

Before I did my little research, my opinion was similar to what has
shown up here on the net.  Now, with a little more information at my
disposal, it all seems quite reasonable.  The moral:  Look before you
flame (I didn't, and I got hosed).

                        _emt

------------------------------

End of Usenet Mac Digest
************************
-------